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Systems Development — As Simple As ABC? 

Editorial 



True or False: Buying a computer system is really very simple. First, find out how much you can afford to spend. 
Call a few companies and arrange for demonstrations. Then, after choosing the computer you like best, have it 
programmed. Presto, a new system is ready for installation as the heartbeat of your corporate enterprise. Easy, 
right? 


Wrong. Such a course of action practically guaran¬ 
tees disaster. Yet seat-of-the-pants planning for the 
development of new computer systems is the single, 
most common error made by managers who rush to 
acquire the latest fruits of data processing design. 
Even among those who recognize the dangers of 
hasty planning, inadequate analysis of the opera¬ 
tional requirements of a new system often leads to 
disappointment or difficulty when the end result is 
tested. As a consequence, time and money are 
wasted, inter-departmental squabbles thrive, and 
management review degenerates into finger-pointing. 


approach to system design: start with a few 
component parts and add or subtract until we get 
distracted by another task...or until the money runs 
out. 

At other times, our problem is the pace of change. 
Our need for data processing services may be 
growing or evolving so quickly that we find it difficult 
to define the goal. By the time we have studied and 
quantified the job at hand, it has already become 
something else. If we are not careful, we end up with 
the perfect way to solve yesterday’s problem. 


Hardware Costs Only 20% 

First of all, we need to fully appreciate the reality that 
the cost of computer hardware represents only 
about 20 percent of the total startup costs of a new 
system. After all, a computer is, by itself, useless. 
Only when software development, personnel, man¬ 
agement involvement, documentation, and training 
are added can we truly claim to have a working 
computer system. Several of these elements are by 
themselves even more important than the actual 
selection of hardware. 

Second, we must understand that unless our 
expectations are fully detailed and our system 
carefully planned in all respects, we can never hope 
for complete success. Our system will not fulfill its 
potential unless every step in its development, from 
concept to reality, has been taken in accordance with 
a comprehensive design and implementation pro¬ 
gram. To proceed otherwise will surely cause us to 
run afoul of Murphy’s law: whatever can go wrong 
will, at the worst possible moment. 

But computer systems are sometimes such behe¬ 
moths, so mammoth in both size and scope, that we 
are baffled by the complexity of the problem. Not 
knowning how to properly take the first step, we rush 
ahead to a later stage, preferring the “hands-on” 


Good Systems Development Is 
Designed to Accommodate Change 



Both of these obstacles need not deter the 
decision maker from a proper course of system 
development. The design of a large, complicated 
system can be approached step-by-step in an orderly 
fashion. A good systems development process is 
designed to accommodate change. Corporate man¬ 
agers can zero in on the “big picture” while technical 
details can be delegated to the appropriate special¬ 
ists. In addition, the entire system can have built-in 
expandability for coping with rapid increases or 
changes in system usage. 


The key to all of this is the adoption of a set of 
standardized and proven systems development 
procedures to ensure that the end users’ needs are 
defined early so the appropriate hardware and 
software can be selected. The operating system, 
languages, special applications packages, and other 
elements of the final system must be specified at an 
early stage in the development cycle...certainly 
before implementation has begun and any hardware 
has been purchased. 


Not all proposals for new systems can or should be 
allowed to proceed through initial review into 
planning and development stages. Increasingly, 
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managers realize that the introduction of new 
information systems is a corporate-level decision 
similar in impact to a capital-spending program. This 
is because the system has effects far beyond its initial 
cost, altering productivity and style of the entire 
organization. Before the green light can be given, the 
benefits of the new system must be weighed against 
factors of cost, disruption, and the expected 
improvement of service. A good systems develop¬ 
ment procedure includes checkpoints early in the 
process at which unsuitable projects can be termi¬ 
nated before they have unneccesarily drained the 
organization’s resources. 

If the go-ahead is given, the systems development 
plan can proceed from generalities to specifics, with a 
timetable and a set of specifications which guide the 
development team along each page. Management is 
able to review progress at predefined intervals and be 
assured that the original goals have not been lost in 
the translation from concept to reality. The pro¬ 
cedure assists in the control of costs, schedule, and 
functionality. 

To sophisticates of the industry, the use of a stepwise 
development procedure is hardly a new idea. After 
one or two attempts at putting together a new 
system, they realize the importance of controls and 
checkpoints. The perils of systems development are 
likely to ensure that the first-time manager will be 
more of a realist — and more of a planner — the next 
time around. 

But while some foresight is surely better than none, a 
comprehensive systems development process is 
needed which asks all the relevant questions at the 
right times and of the right people. We really need a 
sort of road map to guide us through the maze of 
decisions that must be made on the way to a working 
system. 

In this issue, we are happy to present such an 
approach. Extracted from Managing the Systems 
Development Process, by Charles L. Biggs, Evan 


G. Birks, and William Atkins of Touche Ross and 
Company,* the following article outlines the problem 
and presents a set of steps and phases needed during 
the development cycle. We present this portion of 
the book, prior to its publication next year by 
Prentice-Hall (with permission of the publisher) as a 
benefit of association membership. The ideas 
contained in the article are of great significance to all 
of us; they are not widely known, and it is well worth 
the effort to become familiar with them. 

Even with a good plan of action, we can hardly expect 
the systems development process to be as simple as 
ABC. After all, Murphy’s Law has not yet been 
repealed. But though the journey from concept to 
finished system is long and sometimes arduous, we 
can surely eliminate the unwanted side trips that 
make it an unneccesarily treacherous path. And, 
most important, we can be assured of reaching our 
goal — a smooth-running new information system, 
designed from the beginning for success. hs 



'Special thanks to David Wilson, ACU’s Time-Sharing Section 
Chairman, for bringing this manuscript to our attention. 
















Introduction To The Systems Development Process 

A Primer For Users 


By Charles L. Biggs, Evan G. Birks, and William Atkins 
Touche Ross & Co. 

There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the 
creation of a new system. For the initiator has the enmity of all who would profit by the preservation of the old 
system and merely lukewarm defenders in those who would gain by the new one. This was written in the year 
1513 by Machiavelli and continues to hold true today for those who strive to develop new systems. 


Over the last few decades, most new systems have 
involved automated data processing techniques. 
Starting with the early punched card tabulating 
machines and progressing to today’s sophisticated 
general purpose, mini and micro computers, the 
term “system” has gained a broad spectrum of usage 
and meaning. Hence, we have grown familiar with 
terms such as: IBM systems, data entry systems, 
operating systems, data base management systems, 
telecommunications systems, and many more. The 
context in which we use the term in this article is in 
the general sense applying to all of the components 
which make up a system, i.e., the people, policies, 
practices, procedures, and processing techniques. 

It is important for the manager not to lose sight of the 
many aspects which must be considered when 
developing a new system. It is not just a technical 
computer process; to the contrary, it often drastic¬ 
ally affects and changes the basic fabric and 
operation of the organization. Therefore, the man¬ 
ager responsible for developing a new system must 
be more than a skilled technician applying his trade. 
The manager must deal with the organizational, 
operational, and economic considerations, as well as 
the technical considerations. 

In the early years of computerized data processing 
(the late 1950’s and early 1960’s), the vast majority of 
business “systems” were intra-departmental finan¬ 
cial applications which had been designed for and 
converted from unit record punched card systems. 
Many of the early general purpose computer systems 
did not have magnetic tape or disk storage and were 
simply a faster method for processing the punched 
cards, making the computations, and printing the 
reports in one step. These application systems, 
much as the earlier unit record punched card 
systems, were economically justified on the basis of 
eliminating steps and clerical effort. As computers 
became more in vogue in the early 1960’s, manage¬ 
ment went through a subtle change in their decision 


making related to EDP (electronic data processing). 
The change related to a shift away from requiring 
economic justification prior to embarking on new 
application systems development projects or on 
upgrading computer hardware. Management seem¬ 
ed to take the position that even though they would 
not necessarily save money, the use of computers 
would represent an improved method of operation 
and provide for future growth. When economics 
were considered, they were often relegated to future 
cost containment. At the same time, data processing 
personnel were mostly specialized technicians pro¬ 
gramming and operating the computers. They 
showed few signs of being able managers and in 
general followed the direction and recommendations 
of the computer manufacturer’s sales personnel. 
Management, during this period, tended to abdicate 
its responsibility for EDP due to a lack of technical 
understanding presumed to be required. 

As the middle era (the mid-1960’s through the 
mid-1970’s) of computerized data processing ar¬ 
rived, it was heralded by third generation computers 
which were to provide comprehensive MIS (manage¬ 
ment information systems). These general purpose 
computers with miniaturized solid logic technology 
and integrated circuits captured the attention of 
most management in larger organizations, who by 
now felt compelled to keep current with the ever- 
changing world of computers and data processing. 
The concept of the new MIS crossed organizational 
lines and integrated all information elements neces¬ 
sary for timely management decision making. To 
achieve this concept, the development and imple¬ 
mentation strategy in most cases was to convert the 
existing application systems to operate on the new 
computers and concurrently begin planning for an 
integrated MIS. Needless to say, few MIS projects 
were ever completed. In the meantime, increasing 
volumes and new application systems, combined 
with less processing throughput than anticipated, 
caused healthy growth for the computer manu- 
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facturers. 

In the 1970 recession, the future promise of the 
computer was for the first time insufficient to 
maintain the pace of demand. Management seemed 
to be taking a second look and asking how to get 
more results for the cost. Third party leasing 
companies rapidly appeared and experienced signifi¬ 
cant growth by being able to offer 10 percent, 15 
percent, 20 percent, and more savings on computer 
equipment. However, these savings provided only 
temporary relief from the ever increasing costs of 
EDP. Data processing personnel were beginning to 
face the demands of being managers. They were 
being asked to justify expenditures, to get more 
results from the costs being incurred, to reduce 
costs, to provide reports on a timely basis and to 
explain the seemingly inescapable cost and time 
overruns on application development projects and 
hardware conversions. 

In the late 1970’s and early 1980’s, we appear to be in 
a new era. This new era is one that will be 
characterized by management —management that 
effectively utilizes computer technology to achieve 
cost effective results. For example, mini-computers 
and microcomputers have proven themselves tech¬ 
nologically, and the capability exists for efficient 
teleprocessing over computer controlled communi¬ 
cations networks. The data capture and data entry 
technology exists to provide more efficient and 
accurate input. Vastly improved efficiency is be¬ 
coming available in operating systems software, data 
base management software, and programming 
languages. Yet with all this technology, many of the 
application systems being processed today have not 
been resystematized or substantially redesigned to 
be cost effective in this new era. 

The Nature Of The Problem 

The fundamental problem in early computer systems 
development projects was that they were considered 
to be mostly technical and, therefore, were almost 
completely turned over to technically trained com¬ 
puter personnel. Little thought was given to the 
needs of the user and the environment the new 


computerized application system would be serving. 
In many cases, technically successful computer 
system projects were operationally cumbersome and 
difficult for the users, and they never achieved the 
originally forecast results. During the middle era, 
computer system projects were becoming in¬ 
creasingly complex, crossing organizational lines, 
and affecting the traditional methods of operation. 

One of the primary reasons underlying the often 
unfulfilled promise of computers and data processing 
is the lack of understanding and effective practice of 
basic management techniques by systems and data 
processing personnel. Even the rudimentary funda¬ 
mentals of management (planning, organizing, exe¬ 
cuting, measuring, and correcting) are often not able 
to be articulated or demonstrated to be in tangible 
existence by systems and data processing organiza¬ 
tions. These basic management techniques must be 
introduced, practiced, ingrained, and enhanced if the 
promise of the computer is to be fulfilled. These 
management techniques are integral to successfully 
Managing the Systems Development Process. 

The first step to improving the management of the 
Systems Development Process is to define the thing 
to be managed in an orderly and logical fashion. This 
is done with the full awareness that all computer 
systems projects are different, just as people’s 
fingerprints are different. The definition is made with 
the awareness that the Systems Development 
Process could be categorized into its logical com¬ 
ponents, just as most people’s ten fingers can be 
classified, e.g., two index fingers, one left and one 
right, etc. 

The second step to improving the management of 
the Systems Development Process is to define a 
methodology or management process for managing 
a systems project. This management process is 
defined so that it can accomodate a wide variety of 
project planning, measuring, and reporting tech¬ 
niques including PERT, CPM, and many commer¬ 
cially available approaches. These two steps, de¬ 
fining the process to be managed and defining the 
management process to be utilized, create the bridge 
connecting general management and technical 








resources. 

Management should continually be aware of certain 
exposures that exist whenever systems develop¬ 
ment activities occur. The more common of these 
include: 

• Exposure to fraud - systems that include deliber¬ 
ate misapplication of transactions; 

• Exposure to inadequately defined systems that 
result in competitive disadvantages to an organi¬ 
zation; 

• Exposure to projects that consume excessive 
costs in development or ongoing operations; 

• Exposure to erroneous business decisions based 
on inaccurate, misleading, or untimely information 
from a new system; 

• Exposure to costly interruptions to ongoing 
business operations that result from insufficiently 
tested new systems, poor backup and recovery 
procedures, or inadequate conversion and imple¬ 
mentation plans; 

• Exposure to systems that produce unacceptable 
accounting information or inadequate audit trails. 

Although implied from the above exposures, it is 
important to summarize the primary causes: 

• Incomplete economic evaluations, 

• Inadequate user or technical specifications, 

• Systems design errors, 

• Unmaintainable application systems, 

• No project kill points, 

• Poor communications, 

• Technical self-gratification, 

• Personnel incompetency, 

• Temptations for fraud, 

• Management abdication. 

Existence of these exposures should not deter 
management in seeking to obtain new information 
systems for the organization. Rather, awareness of 
these exposures should encourage management to 
establish and maintain adequate controls to mini¬ 
mize the inherent risks associated with the Systems 
Development Process. In general, these controls 
involve: 

• A structured systems development methodology, 

• A formalized project management process, 


• Adequate systems documentation, 

• Frequent management and user reviews and 
approvals, 

• Timely technical reviews and approvals, 

• Appropriate auditor participation, 

• Comprehensive systems tests, 

• Controlled staff hiring and training programs, 

• Thorough post implementation reviews. 

The systems development process and management 
controls over this process are the primary elements 
of the balance of this article. 

Where Does This Methodology Fit? 

Most organizations larger than the smallest proprie¬ 
torships and professional groups have begun to 
develop some interest in strategic planning. In very 
large complex organizations, planning has often 
become the competitive difference in the market¬ 
place. Other organizations continue to talk a lot 
about planning without achieving much in the way of 
results. Some smaller organizations view planning as 
having the CEO hold discussions about a decision 
before it is made public. In any event, there seems to 
be an emerging agreement that top management 
should be responsible for establishing long-term 
objectives; defining general business or operational 
strategies; and setting specific measurable goals or 
tactical targets to be achieved within a given time 
period. The objectives and goals — supported by 
strategies and tactics — require plans and programs 
that specifically define what is to be done, when, who 
is responsible, and what resources are to be applied. 

This methodology is appropriate for developing the 
specific plans and programs called for by the systems 
projects that support an organization’s objectives 
and goals. It specifically defines the phases of the 
Systems Development Process — planning, require¬ 
ments, development, implementation, and main¬ 
tenance. 

Who Should Be Involved? 

The Systems Development Process should be 
integral to supporting top management’s objectives, 







goals and operating plans. This requires an appro¬ 
priate involvement by each level of management. 
Just as it would not normally be expected that the 
chief executive of an organization would make 
specific decisions on technical details, it should not 
be expected that technical personnel and a project 
team make decisions on the organization’s objec¬ 
tives, goals, and operating plans. 

In most cases, however, all of the parts of the 
organization that will be affected should be involved 
in managing the Systems Development Process. 
This begins at the top with senior management and 
includes all levels of management. Generally, senior 
management establishes the objectives and goals of 
the programs. Then, middle management conducts 
programs and projects. 

The appropriate organizational checks and balances 
that normally exist for other operations are also 
required in systems development projects to reduce 
the risks of partial or complete failure. In many cases, 
though, organizations have gone overboard in 
attempting to get management involvement either 
directly or on steering committees. Examples of 
inappropriate top management involvement include: 
making detailed technical presentations on systems 
design to management who lack sufficient exposure 
or background to make a competent evaluation of 
the result; asking top management to approve the 
purchase of hardware and software components 
without proper costs and benefits analyses to 
support the request; and generally approaching 
management with technical issues which are not put 
into proper context with the mission of the overall 
organization. 

As consultants to management, we have stressed for 
many years the need for “appropriate” involvement 
in managing the Systems Development Process. In 
general, top management should view systems plans 
in the context of objectives, goals, and strategic plans 
for the organization. In a practical sense, these 
elements are somewhat interactive and modifi¬ 
cations to both occur as they both mature. 

Middle management’s programs, projects, and 


operating plans should cause them to have very 
direct involvement in assessing, approving, and 
“owning” the systems plans. All of these elements — 
programs, plans, and systems — should be pre¬ 
sented in context to top management for their review 
and decision. Operating management should then be 
responsible for the detailed planning, execution, and 
management of approved systems projects. 

All three levels of management require an agreed 
upon methodology to effectively communicate sys¬ 
tems development plans and progress. They should 
all understand what the phases of the systems 
project will be, what the standard steps are that will 
occur in each phase, and what “end items” or results 
will be accomplished. Then, when communicating 
between the project team and various levels of 
management on project plans or status, reasonable 
understanding should result. 

The project team in most cases should include 
personnel from the user organization, from the 
technical organization, and from other outside 
resource organizations as required. In many cases, 
representation from the user organization is the 
missing link. Often the systems organization is 
expected to and tries to make up for this missing 
element by having a systems analyst be responsible 
for both the operational and systems aspects of the 
project. This becomes increasingly difficult as more 
systems projects address basic business operations 
such as order processing, logistics management, and 
production control. These projects require more 
operations analysis and result in more significant 
impacts throughout the organization. Requiring a 
systems analyst to be responsible for both roles 
seldom accomplishes the results that were initially 
anticipated. Therefore, a new function has emerged 
to which we refer as our “operations analyst.” The 
operations analyst is preferably a member of the user 
organization, but may be a member of the systems 
group. 

The Role Of The Operations Analyst 

The operations analyst is the catalyst for and the 
agent of change for improvements in operations, 






systems, and management. The operations analyst 
works in concert with line management to identify 
and evaluate opportunities for cost effective im¬ 
provements and subsequently works with opera¬ 
tions management to implement approved recom¬ 
mendations. Clarity of thought and expression 
coupled with effective interpersonal skills are man¬ 
datory. The operations analyst is project oriented 
and works hands on through implementation to 
achieve results. Implemented results are the meas¬ 
ure of the operations analyst’s success even though 
operations management has ongoing responsibility. 
The operations analyst’s career path is into line 
management from a background that could include 
engineering, manufacturing, accounting, finance, or 
systems analysis. 


The operations analyst should have demonstrated 
capability in: organization and operations; situation 
analysis and problem definition; operations and 
systems concepts for problem solving; systems 
analysis and conceptual design; feasibility analysis 
and cost benefits evaluation; and systems project 
management including planning, requirements, de¬ 
velopment, and implementation. The operations 
analyst should also have general awareness of: 
computer technologies needed to solve operating 
problems; computer systems technical design; sys¬ 
tems specifications and procedure preparation. 

Due to the variety of definitions of the experience 
and skills appropriate for the members of a systems 
project team, the following chart summarizes the 


SYSTEMS PROJECT 


SUMMARY OF EXPERIENCE AND SKILL REQUIREMENTS 


Experience and Skills 


Operations Systems Technical 

Analyst Analyst Analyst 


General operations and organization. A 

Situation analysis/problem definition. A 

Systems concepts/problem solution. A 

Systems analysis/general design. A 

Cost benefits/feasibility. A 

Systems projects planning and management. A 

Computer techniques to solve business problems .. B 

Applications system design. B 

Systems specifications. B 

Procedures, controls, and training . A 

Programming management. B 

Systems testing. A 

Systems conversion. A 

Technical specifications. C 

Programming and testing. C 

Hardware evaluation and selection. C 

System software evaluation and selection. C 

Data base design and selection. C 

Data communications analysis and network design . C 


B 

B 

B 

B 

B 

A 

A 

A 

A 

A 

A 

A 

A 

B 

B 

B 

B 

B 

B 


C 

C 

C 

C 

C 

C 

B 

B 

B 

B 

B 

B 

B 

A 

A 

A 

A 

A 

A 


Programmer 

Analyst 

C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

B 

B 

B 

A 

A 

B 

B 

C 

C 


A 


Demonstrated Capability B 


General Awareness 


C 


Limited Exposure 
























general mix that is appropriate. As any project 
progresses through the various phases and steps, 
the experience and skill requirements change. This 
normally results in personnel changes for the project 
team in order to complete the necessary activities 
and tasks. 

Overview Of The 
Systems Development Process 

The Systems Development Process is a compre¬ 
hensive guideline for creating new information 
systems. It is a generalized process that is appro¬ 
priate for all systems development projects. It is also 
highly flexible and adaptable to individual situations. 
Although technical in nature, the Systems Develop¬ 
ment Process is primarily a business management 
process that provides a structured approach for a 
multi-discipline group involved in any project. 

The approach to systems development is charac¬ 
terized by breaking down the total job into a series of 
manageable units, each of which is further broken 
down into controllable job assignments that can be 
defined, analyzed, evaluated, and budgeted with a 
degree of assurance. Further, the approach recog¬ 
nizes the importance of structuring the individual 
work segments to produce end products and 
determining these end items in advance. Uniform, 
predefined end products do not limit or preclude 
creativity. They provide instead a consistent struc¬ 
ture within which to display creativity. The end 
products also give management something against 
which to compare progress and quality. Thus, no 
matter what the systems project is to produce, there 
are interim points at which results can be evaluated 
and measured against known standards. 

The Systems Development Process uses a consis¬ 
tent set of terms to describe this top-down approach 
to breaking the total job into logical, functional parts. 
The complete development process has four phases, 
each of which has several steps containing a group of 
standard activities. Four phases encompass the 
entire systems project: 

• Phase I: Systems Planning 

• Phase II: Systems Requirements 


• Phase III: Systems Development 

• Phase IV: Systems Implementation 

At the completion of each of the first three phases, a 
major end product has been created containing the 
results of that particular phase and plans for 
subsequent phases. These products are key factors 
in management’s review, evaluation, and determina¬ 
tion of whether or not to proceed to the next phase. 
A project may be terminated or redirected at each 
point if it is not economically, technically, or 
politically viable (or if it is not important enough to 
warrant the use of available project resources). At 
the end of the fourth phase, the new system is in 
operation and an evaluation is prepared for manage¬ 
ment to review actual versus planned results. A fifth 
“phase” —Systems Maintenance — contains the 
repetitive process used to maintain and enhance a 
system after it is installed. 

Within each phase, a series of steps exists each of 
which is a logical part in accomplishing the objectives 
of the particular phase. The approach emphasizes 
controllable work units that can be defined, ana¬ 
lyzed, evaluated, and budgeted with a degree of 
assurance. In addition, it is structured to produce 
predefined end products that document results and 
provide a basis to measure progress and quality. 

Phase I - Systems Planning begins the Systems 
Development Process by formalizing conceptual 
changes and requests received for new systems. The 
feasibility of pursuing further development is deter¬ 
mined through identification of the probable charac¬ 
teristics, costs, and benefits of implementing the 
requested system. The phase ends with a decision to 
terminate or approve the next phase. The steps in 
Phase I are: 

• Step 1 : Initial Investigation 

• Step 2 : Feasibility Study 

Phase II - Systems Requirements provide the 
detailed foundation upon which the technical pro¬ 
grams and procedures will be developed. Its primary 
emphasis is on user operations and environment. It 
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Terminal Users Move Toward 1200 BPS Interactive Computing 


by 

Stuart Mathison, V.P. 

Telenet Communications Corporation 


In the early 1970’s most timesharing users accessed their computer systems with 110 bps teletypewriter 
terminals. Later in the 1970’s, when 300 bps (bits per second) teleprinter terminals became readily available, 
users naturally converted from 110 bps to 300 bps. The increase in print speeds meant reduced^ holding 
time , and consequently reduced communications and computing costs. Today approximately 90 /o of the 
terminals in the U.S. used to access time-sharing systems operate at 300 bps. 

It now appears likely that this same migration to higher speed terminals will be the pattern in the 1980’s; 
users are now beginning to move from their 300 bps terminals toward 1200 bps terminals, which are more 
efficient for time-sharing and other interactive applications. Why is this happening? 


There appear to be four principal factors stimu¬ 
lating the migration to 1200 bps terminals: 

(1) The availability of low-cost 1200 bps terminals, 
especially the popular CRT-display models 

(2) The availability of full-duplex 1200 bps 
modems offered by Vadic and the Bell 
System 

(3) The availability of statistical multiplexers, 
providing low-cost 1200 bps communications 
service, and 

(4) The nationwide 1200 bps public-dial services 
offered by the Telenet and Tymnet packet- 
switched networks, also providing low-cost 
1200 bps communications service. 

Efficiency and Productivity Improved 
by Use of 1200 bps Terminals 

The pattern of data flow in interactive time-sharing 
gives 1200 bps operation distinct advantages over 
300 bps. The typical interactive session consists of 
a terminal user entering data at a very slow 
keyboard entry speed, typically one or two 
characters per second. The host computer re¬ 
sponds with substantial amounts of data at the 
maximum speed the terminal can handle. In terms 
of character volumes, a typical 300 bps terminal 
user will enter approximately 2,000 characters 
during a one-hour session, and will receive 
approximately 20,000 - 30,000 characters of data 
from the computer. With this typical data flow 
pattern, the terminal will be printing (or displaying) 
the data for approximately 15 minutes of each 


hour. 

A terminal operating at 1200 bps requires less than 
four minutes to print or display the same output 
data. So switching to a 1200 bps terminal will 
reduce the holding time for a given application and 
character volume by approximately 15-20%. This 
can be directly translated into dollar savings, since 
both communications and computer usage costs 
are based largely on holding time. 

Operating at 1200 bps also noticeably increases 
productivity. The man-machine relationship be¬ 
tween the user and the host computer improves 
immediately, because the user’s wait for output is 
shortened dramatically. He can enter the next 
command before he has lost his train of thought! 
Furthermore, a 1200 bps terminal prints at 
approximately the average reading speed, and 
therefore eliminates yet another bottleneck be¬ 
tween the user and the remote computer system. 

Introduction of 1200 bps Full-Duplex Modems 

The chief obstacle to 1200 bps interactive 
computing, until recently, was the unavailability of 
full-duplex dial-up 1200 bps modems. Until the 
introduction of the Vadic 3400 modem and the Bell 
212 modem, in 1977 and 1978 respectively, full 
duplex 1200 bps service was simply not available 
on a dial-up basis to access time-sharing systems. 

Although half-duplex, dial-up, Bell 202 1200 bps 
modems had been available for many years, they 
were not suitable for interactive time-sharing 
applications for two reasons. First, they require the 
use of costly buffered terminals, which employ a 











block-oriented error control protocol; and second, 
they introduce a fraction of a second delay to “turn 
the line around” each time the direction of 
transmission was changed. 

Full-duplex transmission is preferred for time¬ 
sharing applications for another reason — error 
control. Since dial telephone lines, which are 
commonly used to access time-sharing systems, 
are prone to cause occasional errors in transmitted 
data, many time-sharing systems use an error 
control technique called echoplexing. In echo¬ 
plexing, the data entered at the keyboard is not 
immediately printed but is transferred to the host 
computer (or the multiplexer/concentrator) then 
echoed back to the terminal for printing. This 
technique allows the terminal operator to verify 
that the data received by the host computer was 
the same as the data he entered at the keyboard. 
Echoplexing requires the use of full-duplex mo¬ 
dems on the dial access telephone lines. 

Full-duplex communication, in contrast to half¬ 
duplex communication, enables the host to provide 
very responsive, interactive service. The user 
obtains an almost immediate response when he 
hits the break or interrupt key or enters an escape 
character. Host computers can then easily perform 
such functions as command recognition, and 
character-by-character text editing with terminals 
operating in full-duplex mode. 

The Vadic 3400 and the Bell 212 full-duplex 
modems utilize a different set of inter-modem 
signalling frequencies and are therefore incom¬ 
patible with one another. Initially, a Vadic 1200 bps 
modem could only communicate with another 
Vadic, and a Bell 212 with another 212. However, 
Vadic has recently introduced a dual-compatibility 
modem, the Vadic Model No. 3467, which enables 
a user equipped with either a Bell 212 modem or a 
Vadic 3400 modem to communicate with the Vadic 
3467. This is expected to further accelerate the 
migration toward the use of 1200 bps terminals. 


1200 bps Terminals Getting Cheaper 

Cathode Ray Tube (CRT) display terminals consist 
largely of electronics, rather than electromecha¬ 
nical components. As a result of the decline in the 
cost of digital electronics over the past decade, 
there are now many high-speed CRT terminals that 
cost less than $1,000 in single unit quantities. Most 
of these can operate at 1200 bps. 

1200 bps teleprinter terminals have also been 
declining in cost, although not as rapidly as the 
CRT display terminals. Still, there are some 
applications for which hardcopy output is essential. 
The teleprinter terminals fill this need. Tables 1 and 
2 list some of the more popular 1200 bps terminals 
in each class. 

How the Public Packet Networks 
Stimulated 1200 bps Communications 

Over the past two years both Telenet and Tymnet 
have introduced public dial full-duplex 1200 bps 
service in an increasing number of U.S. cities. 
Initially public dial-in 1200 bps service utilized the 
Vadic 3400 modems. When Bell introduced the full- 
duplex 212 modem in 1978, Telenet and Tymnet 
offered public dial 1200 bps service supporting the 
Bell 212 modems as well. 

The geographic availability of public dial 1200 bps 
service on the Telenet and Tymnet networks has 
continually expanded. As of this writing, both 
companies offer local dial 1200 bps service in 
several dozen metropolitan areas, as well as 
nationwide In-WATS service at 1200 bps. By the 
end of 1979, most of the cities served by Telenet 
and Tymnet are likely to provide public dial 1200 
bps support. 

The communication charge for public dial 1200 bps 
service in a packet network has two components 
— a connect time charge and a traffic charge. In 
the case of Telenet, the connect time charge is 
$3.25 per hour and the traffic charge is $.50 per 
kilopacket. A typical 1200 bps terminal user will 






send and receive between 1 and 1 y 2 kilopackets per 
hour, depending on the nature of the application 
and the total character volume transmitted. Thus, 
the total hourly cost will be approximately $4.00. 

It is significant that Telenet’s charges for 1200 bps 
service are approximately the same as its charges 
for 300 bps service. The public dial connect time 
charge is $3.25 per hour for both 300 and 1200 bps 
terminals; the traffic charge of $.50 per kilopacket 
is also the same for both. The 1200 bps terminal 
will transfer about the same number of packets per 
hour as the 300 bps terminal, but the 1200 bps 
terminal will typically receive “fuller” packets —i.e., 
packets containing more user data — and 
therefore will receive more characters per hour 
than the 300 bps terminal. 

What About Stand-Alone Host Systems 
Supporting Full-Duplex 1200 bps Service? 

Host computers not connected to Telenet or 
Tymnet can support full-duplex 1200 bps terminals 
if the hosts have dial-in ports equipped with Bell 
212 or Vadic 3400 modems, or if the hosts are 
accessed through multiplexers or concentrators 
equipped with such modems. This is frequently 
impractical, however, since to do so using either 
In-WATS lines or multiplexers is extremely costly 
and to provide a small rotary of dial-in 1200 bps 
ports on concentrators would usually be une¬ 
conomic due to low dial port utilization. As a 
result, many interactive host systems offer 1200 
bps access only through Telenet or Tymnet. 

Hosts connected to the public packet networks 
can support full-duplex 1200 bps terminals if the 
hosts interface to the network using the inter¬ 
national standard X.25 protocol, or if the hosts are 
connected to the network utilizing 1200 bps 
terminal emulation interface ports. Most emulation 
interface ports utilize flow control techniques, such 
as the “transmit-on” and “transmit-off” characters 
(X-on/X-off) in order to prevent data overflow, and 
to permit the same 1200 bps host ports to be 
accessed by lower speed terminals (110-300 bps) as 
well. 



The Racal-Vadic VA3434 acoustic coupler that operates at 1200bps. 


1200 bps Terminals are 
a Sure Bet for the 1980s 

1200 bps terminals offer so many advantages for 
interactive computing — the reduction of compu¬ 
ting and communications costs and the simulta¬ 
neous improvement of user productivity, for 
example — that their prevalence is bound to grow. 

At the same time, the migration toward these 
higher-speed terminals is making new business- 
oriented applications feasible for the first time. 
Applications that involve outputting lengthy re¬ 
ports and/or long text files can be accomplished 
quickly and economically. Also, applications de¬ 
signed for the non-computer-oriented user will 
proliferate, since the lengthy, English-like prompts 
and user-assistance statements can be accommo¬ 
dated without introducing substantial delays. 

Even though most portable, acoustically coupled 
terminals will probably continue to operate at 300 
bps for some time to come, within the next few 
years the majority of interactive computing applica¬ 
tions may well be performed using 1200 bps CRT 
display or teleprinter terminals. 






Tabic 1 


Tabic 2 


CRT Display Terminals 
Which Operate At 1200 BPS 


Make/Model 

Approx. Single 
Unit Price 

AT&T Dataspeed 40/2 

* 

Applied Digital Data Systems (ADDS) 

Consul 520 

$1,600 

Consul 980 

$2,800 

Regent 200 

$1,800 

Beehive International 

Micro Bee 

$1,000 

Micro Bee 1A 

$1,400 

Micro Bee 2 

$1,700 

Datamedia Corporation 

Elite 1520 

$2,500 

Elite 1520 Portable 

$2,500 

Elite 1521 A 

$1,200 

Hazeltine 

1400 

$ 825 

1410 

$ 900 

1420 

$1,000 

1500 

$1,200 

1510 

$1,300 

1520 

$1,600 

Modular 1 

$1,600 

Hewlett-Packard 

HP 2640 B 

$2,600 

HP 2645 A 

$3,500 

HP 2649 A 

$2,150 

Infoton 

1-200 

$1,200 

1-400 

$1,500 

Lear-Siegler 

ADM-3A 

$ 895 

Perkin-Elmer 

Model 1100 

$1,500 

Owl 1200 

$2,200 

Research Inc. 

Teleray 3541 

$1,200 

Teleray 3741 

$1,300 

Tektronix 

4024 

$3,000 

4025 

$4,000 


Teleprinter Terminals 
Which Operate At 1200 BPS 


Make/Model 

Approx. Single 
Unit Price 

Anderson Jacobson 

AJ 860 

$2,800 

Digital Equipment Corp. (DEC) 

LA 180 

$3,000 

DI-AN Controls Series 30 KSR 

$2,200 

Execuport 1200 

$3,500 

General Electric 

Terminal 1200 

$2,000 

Lear-Siegler 

Model 220 

$1,750 

Logabox 
dXL 180/KSR 

$4,000 

Teletype 

Model 40/2 KDP 

$4,900 

Texas Instruments 

820 KSR 

$2,400 

Xerox 1760 

$2,990 


*Price for AT&T Dataspeed 40/2 depends 
upon local telephone company 







(The Systems Development Process — Continued from Page 10) 

ends with another review and decision to terminate 
or proceed to the next phase. The steps in Phase II 
are: 

• Step 1: Operations and Systems Analysis 

• Step 2: User Requirements 

• Step 3 : Technical Support Approach 

• Step 4: Conceptual Design and Package 

Review 

• Step 5: Alternatives Evaluation and 

Development Planning 

Phase III - Systems Development begins with an 
accepted conceptual design approach and ends with 
a completely developed new system that has been 
thoroughly tested and prepared for implementation. 
For many projects, this phase may be repeated 
several times in order to develop multiple sub¬ 
systems identified in the previous requirements 
phase. Purchase of an application package generally 
reduces the scope of work in this phase but seldom 
completely eliminates any step. Phase III ends with a 
review of development and testing results and an 
agreement by all parties that the new system should 
be implemented. The steps in this phase are: 

• Step 1: Systems Technical Specifications 

• Step 2: Technical Support Development 

• Step 3: Applications Specifications 

• Step 4: Applications Programming and 

Testing 

• Step 5: User Procedures and Controls 

• Step 6: User Training 

• Step 7: Implementation Planning 

• Step 8: Conversion Planning 

• Step 9: Systems Test 

Phase IV - Systems Implementation contain the 
actual initiation of new programs and procedures 
and the termination of old processes. For many 
projects, this phase is repeated several times to 
implement multiple subsystems or to install the 
system in multiple locations. The steps in Phase IV 
are: 

• Step 1: Conversion and Phase 

Implementation 

• Step 2: Refinement and Tuning 

• Step 3: Post-Implementation Review 


CORPORATE ASSOCIATE MEMBERS 

ADP Network Services 

American Terminal Leasing 

Avco Computer Services 

Boeing Computer Services Company 

CallData Systems 

Citibank-Interactive Computing Center 
Corporate Time-Sharing Services, Inc. 
Datanetwork, Honeywell, Inc. 

G.E. Information Services Company 
Informatics - Data Services Div. 

Insco Systems Corporation 
I.P. Sharp Associates, Ltd. 

Litton Computer Services 
Martin Marietta Data Systems 
Metrocom Inc. 

Minicomputer Modeling, Inc. 

National Computer Network 
On-Line Systems, Inc. 

Quantum Science Corporation 
R.A.I.R., Inc. 

Rapidata, Inc. 

Scientific Time-Sharing Corporation 
SDC Search Service 
Sun Information Services 
Telenet Communications Corporation 
Time-Sharing Resources, Inc. 

Trendata 

United Computing Systems 

University Computing Company 

Vocal Interface 

Warner Computer Systems 

Western Union - Data Services Company 

Zeta Research 

Companies supplying computing products or services 
are eligible to apply for Corporate Associate Member¬ 
ship by writing to the Association. 


Finally, it is important to remember that the Systems 
Development Process as introduced in this article is 
intended to be a guideline, not a rigid set of 
instructions. The standard approach explained here 
makes it possible to plan, control, and evaluate 
progress during the Systems Development Process 
without inhibiting the necessary analytical and 
creative work required to produce successful new 
systems. In addition, this structure allows manage¬ 
ment to make and monitor incremental commit¬ 
ments, providing the ability to impact interim results. 
This is an important key to an organization’s effective 
management of the Systems Development Process. 
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Association of Computer Users — Chapters, Local Contacts and Special Interest Contacts 


ALABAMA 

Winston Brooke 
Anniston — TSS Local Contact 
Brooke, Freeman, Berry & McBrayer 
( 205 ) 238-1040 

ALBERTA 

Brian McCullough 

Sherwood Park — HHS Local Contact 
( 403 ) 464-5069 

ARKANSAS 

Gene Dugger 

Searcy — SCS Local Contact 
Harding College 
( 501 ) 268-6161 

CALIFORNIA 

Richard Dumas 

Mountain View — TSS Local Contact 
Commodity Research Institute 
( 415 ) 941-4646 

Frederick Gallegos 
Los Angeles — TSS Local Contact 
U.S. Gen’l Accounting Office 
( 213 ) 688-3809 

Don Hatch 

San Diego — SCS Local Contact 
Christian Mgmt. Consulting Services 
( 714 ) 293-3200 

Jim Rigby 

Brea — SCS Local Contact 
Rodgers & Rigby, CPA’s 
( 714 ) 990-3613 

Frank Slaton 

San Bernardino — TSS Local Contact 
California State College 
( 714 ) 887-7293 

COLORADO 

Michael J. O’Connell 
Denver — SCS Local Contact 
Assoc, of Operating Rm. Nurses 
( 303 ) 755-6300 

CONNECTICUT 

Frank Chew 

Greenwich — TSS Local Contact 
Amax, Inc. 

( 203 ) 622-2824 

Charles J. Clock, Jr. 

Special Interest Contact for 
Educational Applications 
West Hartford Public Schools 
( 203 ) 236-6081 

FLORIDA 

William A. Rousseau 

Pompano Beach — TSS Local Contact 

Alpine Engineered Products, Inc. 

( 305 ) 781-3333 

J. L. YanGoethem 
Miami — SCS Local Contact 
Ryder System, Inc. 

( 305 ) 593-3726 

HAWAII 

Richard Riehle 

Honolulu — SCS Local Contact 
The Printout 
( 808 ) 536-6532 

IDAHO 

Rick Simon 

Boise — TSS Local Contact 
Morrison-Knudsen Company 
( 208 ) 345-5000 

ILLINOIS 

* Leon Stevens 

Chicago - SCS Chairman, SCS 
and TSS Local Contact 
Standard Oil Company 
( 312 ) 856-6689 


John A. Koziol 

Chicago — TSS & SCS Local Contact 
Continental Materials Corp. 

( 312 ) 565-0100 

IOWA 

James E. Lewis 

Marshalltown — SCS Local Contact 
Iowa Valley Comm. College District 
( 515 ) 752-4643 

KENTUCKY 

Clyde Jenkins 

Special Interest Contact for APL 
Humana Inc. 

( 502 ) 589-3790 

LOUISIANA 

W. D. Landry 

Abbeville — SCS Local Contact 
Coastal Chemical Co., Inc. 

( 504 ) 893-3862 

MARYLAND 

R. G. Korbeck 

Baltimore —■ TSS Local Contact 
Baltimore Gas and Electric Company 
( 301 ) 234-6687 

MASSACHUSETTS 

* Stuart Lipoff 

Boston — TSS Local Contact and 
Special Interest Contact for 
Software Standards 
Arthur D. Little, Inc. 

( 617 ) 864-5770 

METRO WASHINGTON, DC. 

Frank E. Rockwell 
Lanham — SCS Local Contact 
Astro Data Systems 
( 301 ) 577-5838 

MICHIGAN 

J. Ben Friberg 

Grand Rapids — TSS Local Contact 
Rapidstan Inc. 

( 616 ) 451-6682 

Tom Hunt 

Cadillac — TSS Local Contact 
Kysor Industrial Corp. 

( 616 ) 775-4646 

* Larry Leslie 

Kalamazoo — TSS Vice-Chairman 
and Special Interest Contact for 
Time-Sharing Administrators 
Upjohn Company 
( 616 ) 323-4000 

MINNESOTA 

L. R. Bakewell 

St. Paul — SCS Local Contact 
Real Estate Dynamics, Inc. 

( 612 ) 698-8891 

MISSOURI 

Dann E. Kroeger 

Kansas City — SCS Local Contact 
Townsend Communications, Inc. 

( 816 ) 454-9660 

NEW JERSEY 

Jim Fitzpatrick 
Special Interest Contact for 
Data Base Applications 
American Broadcasting Corp. 

( 201 ) 488-2345 

Robert J. Loring 

Haddonfield — SCS Local Contact 
Cardiac Long-Term Monitoring SVC 
( 609 ) 795-2220 

* Bennett Meyer 

Wayne — SCS Vice-Chairman, and 
Special Interest Contact for 
Data Security 
Singer-Kearfott 
( 201 ) 256-4000 


Samuel A. Scharff 
Englewood — SCS Local Contact 
Consulting Engineer 
( 201 ) 569-8332 

NEW YORK 

Dr. Dina Bedi 

Special Interest Contact for 
Educational Applications 
Baruch College 
( 212 ) 725-3196 

Terri Gendron 

Briarcliff Manor — TSS Local Contact 
Phillips Laboratories 
( 914 ) 762-0300 

Samuel Leonard 

Elmira — TSS Local Contact 

Thatcher Glass Mfg. Co. 

( 607 ) 737-3459 

Philip N. Sussman 

New York City — TSS & SCS Local Contact 
International Paper Company 
( 212 ) 490-6061 

NEW YORK CITY CHAPTER 
Executive Board: 

Aram Bedrosian 
TWA 

Bion Bierer 
Bristol Myers 
Victor Bittman 

Chase Manhattan 
Charles Browning 
Phelps Dodge 
Dennis Callahan 

Goldman Sachs & Co. 

Chester Frankfeldt 
Continental Group 
Carl Heimowitz 

Harcourt Brace Jovanovich 
Alan Kornbluth 

American Express 
Susan McCain 

Morgan Guaranty 
Arthur Schneyman 
Mobil Oil 
Philip Sussman 

International Paper Co. 

OHIO 

Dennis Bender 

Cincinnati — TSS Local Contact 
Procter & Gamble 
( 513 ) 562-2469 

Ed Casper 

Cleveland — TSS Chapter President 
Diamond Shamrock Corp. 

( 216 ) 694-5566 

Howard Tureff 

Cleveland — TSS Local Contact 
Diamond Shamrock Corp. 

( 216 ) 694-5963 

ONTARIO 

* David Wilson 

Toronto — TTS Chairman, and 
TTS and SCS Local Contact 
P.S. Ross & Partners 
( 416 ) 363-8281 

OREGON 

Paul Gehlar 

Salem — SCS Local Contact 
Oregon Fruit Products Co. 

( 503 ) 581-6211 

PENNSYLVANIA 

Dale Hummer 

Pittsburgh — TSS Local Contact 
Westinghouse Electric Corp. 

( 412 ) 273-6169 


in addition to officers listed below. 


D. T. Wu 

Philadelphia — TSS Local Contact 
DuPont De Nemours & Co. 

( 215 ) 339-6307 

QUEBEC 

Andre Pitre 

St-Laurent — TSS Local Contact 
S.D.S. Inc. 

( 514 ) 744-4454 

TEXAS 

Ralph N. Bussard 

Houston — TSS & SCS Local Contact 
Price Waterhouse & Company 
( 713 ) 654-4100 

Ankarath Unni 
Dallas — SCS Local Contact 
Sun Production Company 
( 214 ) 739-9301 

UTAH 

Melvin D. Nimer 

Salt Lake/Provo — SCS Local Contact 
McNally Mountain States Steel Company 
( 801 ) 785-5085 

VIRGINIA 

John Hudson 

Danville — TSS & SCS Local Contact 
Dan River Inc. 

( 804 ) 799-7101 

W. W. McChesney 
Alexandria — SCS Local Contact 
Country Legend Stores, Inc. 

( 703 ) 370-9850 

WISCONSIN 

Anil K. Bhala 

Green Bay — SCS Local Contact 
L. D. Schreiber Cheese Co. 

( 414 ) 437-7601 

Jack Kochie 

Racine — SCS Local Contact 
Medical Engineering 
( 414 ) 639-7205 

David J. Ritter 

LaCrosse — SCS Local Contact 
LaCrosse Garment Mfg. Co. 

( 608 ) 785-1400 

John J. Stewart 

Wausau — SCS Local Contact 

Van Ert Electric Co., Inc. 

( 715 ) 845-4308 

Paul Thoppil 

Milwaukee — TSS Local Contact 
RTE Corporation 
( 414 ) 547-1251 

Robert Whitney 

Eau Claire — SCS Local Contact 
Owen Ayres & Associates, Inc. 

( 715 ) 834-3161 

LOCAL CONTACTS WANTED 

Become a local contact for your area. 
Your name and telephone number will be 
listed on this page in each issue of 
Interactive Computing, enabling other 
members to contact you with their 
questions. Only users, not suppliers, are 
eligible to apply by writing to the 
Association. Please specify which of the 
following Sections you would like to serve 
for: • Time-Sharing Section 

• Small Computer Section 

• Midi Computer Section 

• Large Computer Section 

• Distributed Processing 

• Word Processing Section 

• Home and Hobbyist Section 


*Council Members for 1979, 
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